Sometimes an application may need to execute code, a third party plug-in for example, which is provided by a source that may be untrusted. When the application calls into this untrusted code the application may expose itself to possible security threats. There can be a higher degree of risk if there happens to be a flaw in the application that can allow the injection of malicious code into a process. An example of this can happen with the interaction between an indexing service and an applications designed to pull the text out of a specific file format so that an indexer can consume it. A document could be sent to a user as an attachment in an email that may require the application to extract textual information from the document. A flaw in the application may exist that when the application is invoked on the attachment to extract the textual information from a document, the attachment, if malicious, may cause a buffer overflow or other form of code injection that, in theory, can call any function in any well-known component on the system.
There may be some options in trying to solve this problem. The application can be made to run under a restricted user token. This can cause the application to not be able to delete files, execute files, modify the registry etc. However, this may not be enough. Some parts of the operating system may still be vulnerable to an attack even with a reduction in permissions. An example of this is that currently the operating system does not allow you to prevent access from network application program interfaces (APIs). If the security threat came from the network, preventing access to resources on the network may be critical, as a compromised program could otherwise start downloading additional malicious code to compromise the entire system.